Implement searchable property for marker schema#4352
Conversation
Codecov ReportBase: 88.37% // Head: 88.36% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #4352 +/- ##
==========================================
- Coverage 88.37% 88.36% -0.01%
==========================================
Files 282 282
Lines 25314 25351 +37
Branches 6826 6828 +2
==========================================
+ Hits 22371 22402 +31
- Misses 2731 2737 +6
Partials 212 212
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
julienw
left a comment
There was a problem hiding this comment.
This looks pretty good to me!
I don't see an upgrader part for these markers: https://searchfox.org/mozilla-central/rev/404408660a4d976e2ac25881cb1e1f2712f2d430/tools/profiler/core/MicroGeckoProfiler.cpp#47-88
do you think we could add one?
| const searchableFields = schema.data.filter((field) => | ||
| searchableFieldKeys.includes(field.key) | ||
| ); | ||
| for (const field of searchableFields) { |
There was a problem hiding this comment.
optional nit:
Doing this in 2 steps look a bit more complicated than how it could be. What about looping on schema.data directly?
for (const field of schema.data) {
if (searchableFieldKeys.includes(field.key)) {
field.searchable = true;
}
}There was a problem hiding this comment.
Same comment for the other versioning file
There was a problem hiding this comment.
Right, changed it, thanks :)
| // 'target' wasn't included in our code before. But I thought this | ||
| // would be a useful addition. |
There was a problem hiding this comment.
good idea! maybe target wasn't existing at the time we implemented the custom search. Not sure :-)
There was a problem hiding this comment.
Yeah, it looks like this was added after the initial implementation.
| case 'FileIO': { | ||
| searchableFieldKeys = [ | ||
| 'filename', | ||
| 'operation', | ||
| 'source', | ||
| 'threadId', | ||
| ]; |
There was a problem hiding this comment.
Is this change necessary? I see it was already done in the gecko code.
There was a problem hiding this comment.
It's probably not. I wasn't sure if they were added initially when we implemented the markers 2.0 or added later but it looks like they are actually added while we are implementing schemas. So we don't need to change them except threadId. We don't have the threadId in the schema, so added it manually.
| markerSchema: MarkerSchema, | ||
| marker: Marker, | ||
| searchRegExp: RegExp | ||
| ): boolean { |
There was a problem hiding this comment.
I wonder if we should set searchRegExp.lastIndex = 0 here too. Currently we should be good, but I'm concerned about how we might use this function in the future too.
There was a problem hiding this comment.
Yeah, that makes sense. Added it.
36961a3 to
35c1c5c
Compare
There was a problem hiding this comment.
Thanks for the review! I addressed your comments. Added the last commit, would you mind taking a quick look on it?
I don't see an upgrader part for these markers: https://searchfox.org/mozilla-central/rev/404408660a4d976e2ac25881cb1e1f2712f2d430/tools/profiler/core/MicroGeckoProfiler.cpp#47-88
do you think we could add one?
Good idea, added it.
| const searchableFields = schema.data.filter((field) => | ||
| searchableFieldKeys.includes(field.key) | ||
| ); | ||
| for (const field of searchableFields) { |
There was a problem hiding this comment.
Right, changed it, thanks :)
| // 'target' wasn't included in our code before. But I thought this | ||
| // would be a useful addition. |
There was a problem hiding this comment.
Yeah, it looks like this was added after the initial implementation.
| case 'FileIO': { | ||
| searchableFieldKeys = [ | ||
| 'filename', | ||
| 'operation', | ||
| 'source', | ||
| 'threadId', | ||
| ]; |
There was a problem hiding this comment.
It's probably not. I wasn't sure if they were added initially when we implemented the markers 2.0 or added later but it looks like they are actually added while we are implementing schemas. So we don't need to change them except threadId. We don't have the threadId in the schema, so added it manually.
| markerSchema: MarkerSchema, | ||
| marker: Marker, | ||
| searchRegExp: RegExp | ||
| ): boolean { |
There was a problem hiding this comment.
Yeah, that makes sense. Added it.
julienw
left a comment
There was a problem hiding this comment.
looks good to me, thanks for checking!
35c1c5c to
8de1e7b
Compare
…rsion 33. When the test was initially added, the markerSchema was missing from the profile. That was invalid because version 33 is the version which started requiring that the markerSchema field is present. In firefox-devtools#4352 we added because the upgrader for version 44 caught the fact that it was missing, because it (rightfully) assumes that it's present. However, since this is a profile of a fixed version, we shouldn't attempt to share code with other tests - anything that's shared will usually follow the most recent format version, whereas this test must make sure the profile it creates complies with the hardcoded fixed version.
…rsion 33. When the test was initially added, the markerSchema was missing from the profile. That was invalid because version 33 is the version which started requiring that the markerSchema field is present. In firefox-devtools#4352 we added because the upgrader for version 44 caught the fact that it was missing, because it (rightfully) assumes that it's present. However, since this is a profile of a fixed version, we shouldn't attempt to share code with other tests - anything that's shared will usually follow the most recent format version, whereas this test must make sure the profile it creates complies with the hardcoded fixed version.
…rsion 33. When the test was initially added, the markerSchema was missing from the profile. That was invalid because version 33 is the version which started requiring that the markerSchema field is present. In firefox-devtools#4352 we added because the upgrader for version 44 caught the fact that it was missing, because it (rightfully) assumes that it's present. However, since this is a profile of a fixed version, we shouldn't attempt to share code with other tests - anything that's shared will usually follow the most recent format version, whereas this test must make sure the profile it creates complies with the hardcoded fixed version.
…rsion 33. When the test was initially added, the markerSchema was missing from the profile. That was invalid because version 33 is the version which started requiring that the markerSchema field is present. In firefox-devtools#4352 we added the missing markerSchema because the upgrader for version 44 caught the fact that it was missing, because it (rightfully) assumes that it's present. However, since this is a profile of a fixed version, we shouldn't attempt to share code with other tests - anything that's shared will usually follow the most recent format version, whereas this test must make sure the profile it creates complies with the hardcoded fixed version.
Fixes #2780.
We also need to land the Bugzilla counterpart here. It Adds
searchable: trueto:nameandcategory.This PR removes the manual filtering that we had and replaces it with checking all the payload's
searchablefields.We also had to add an upgrader for both gecko and processed format and add
searchablefields for these fields, so even though we remove these manual checks, search on older profiles work as expected.I wasn't sure if the performance would be the same but after doing some micro benchmarks, I've found out that it's at lest the same if not better. Here's a before and after running times of that getSearchFilteredMarkerIndexes that I measured.
Deploy preview:
I also got this profile from out spreadsheet that says "Awful lots of markers" :)
Before / After